NEC V850 development

Contents|Previous|Next
NEC V850 development

The following documentation discusses the NEC V850 family of processors for GNUPro tools.

- Toolchain features for V850
- ABI summary for the V850
- Compiler issues for V850
- Assembler information for V850
- Linker information for V850
- Debugger issues for V850
- Stand-alone simulator issues for V850

For more specific information on the V850 processor, see V850 User's Manual, V851 Hardware User's Manual (NEC document #U10954EU1V0UM00, January 1996), V850_EVA (Revision C), and System V Application Binary Interface (Prentice Hall, 1990).
Toolchain features for V850
The following documentation describes the main features of the tools addressing the V850 family of processors.
The V851 version of the V850 family of processors is supported with the GNUPro tools.
The V850 tools support the ELF object file format. To produce S-records, use the GNU linker, `ld` (see Using `ld` in GNUPro Utilities for more information) or `objcopy` (see Using `binutils` in GNUPro Utilities for more information).
For the V850 processor, file names are case sensitive under Unix. Case sensitivity for Windows 95 and Windows NT is dependent on system configuration. By default, file names under Windows 95 and Windows NT are not case sensitive for the V850 processor.
The following case sensitive issues under Unix, Windows 95, and Windows NT apply to the V850 processor.

- command line options
- assembler labels
- linker script commands
- section names

The following case sensitive issues under Unix, Windows 95, or Windows NT do not apply to the V850 processor.

- GDB commands
- assembler instructions and register names

GNUPro Toolkit includes tools for converting legacy source code, originally written for other compilers, into GNUPro compiler (GCC) compliant code.
For the Windows 95/NT toolchain, the libraries install in different locations. Therefore, the Windows 95/NT hosted toolchain requires the following environmental settings to function properly. Assume the release is installed in `C:\USR\CYGNUS` . The <`yymmdd`> variable indicates the release date found on the CD.

    SET PROOT=C:\usr\cygnus\V850-<yymmdd>

    SET PATH=%PROOT%\H-i386-cygwin32\BIN;%PATH%

    SET GCC_EXEC_PREFIX=%PROOT%\H-i386-cygwin32\lib\gcc-lib\

    SET INFOPATH=%PROOT%\info

    REM Set TMPDIR to point to a ramdisk if you have one

    SET TMPDIR=%PROOT%

Note:
The trailing back slash ( `\` ) in ` `GCC_EXEC_PREFIX` ' is necessary.

Programs may be developed for and debugged on the GNUPro Instruction Set Simulator. The ICE (In-circuit Emulator) for V851 1 is in development.

1. See IE-703000-MC-A In-circuit Emulator for V851 User's Manual (from NEC Electronics Inc.) for details.

Cross-development tools in GNUPro Toolkit normally have names that reflect the target processor and the object file format output by the tools (ELF). This makes it possible to install more than one set of tools in the same binary directory, including both native and cross-development tools.
The complete tool name is a three-part hyphenated string. The first part indicates the processor or processor family (`V850`). The second part indicates the file format output by the tool (`elf`). The third part is the generic tool name (`gcc`). For example, the GCC compiler for the NEC V850 family of processors is `V850-elf-gcc`.
The V850 package includes the following supported tools.

Tool Description | Tool Name
--- | ---
GCC compiler | `V850`-`elf`-`gcc`
G++ compiler | `V850`-`elf`-`g++`
C++ compiler | `V850`-`elf`-`c++`
C++ demangler | `V850`-`elf`-`c++filt`
GNU assembler | `V850`-`elf`-`as`
GNU linker | `V850`-`elf`-`ld`
Standalone simulator | `V850`-`elf`-`run`

Binary utilities

`V850`-`elf`-`ar`
`V850`-`elf`-`nm`
`V850`-`elf`-`objcopy`
`V850`-`elf`-`objdump`
`V850`-`elf`-`ranlib`
`V850`-`elf`-`size`
`V850`-`elf`-`strings`
`V850`-`elf`-`strip`

GDB debugger | `V850`-`elf`-`gdb`
Cygnus Insight, the GNUPro visual debugger (Windows 95/NT only) | `V850`-`elf`-`gdbtk`

Important:
The binaries for a Windows 95/NT hosted toolchain are installed with an `.exe` suffix. However, the `.exe` suffix does not need to be specified when running the executable.

ABI summary for the V850
The following documentation discusses the ABI for the V850 processor.

- Data types and alignment for V850
- Calling conventions for V850
- Register allocation for V850
- Stack frame information for V850
- Argument passing for V850
- Function return values for V850

Data types and alignment for V850
The following table describes the data types and their alignment sizes for the V850 processor.

`char` : | 1 byte
`short` : | 2 bytes
`int` : | 4 bytes
`long` : | 4 bytes
`long long` : | 4 bytes
`float` : | 4 bytes
`double` : | 4 bytes
`long double` : | 8 bytes
pointer : | 4 bytes

The stack is aligned to a four byte boundary. One byte is used for characters (including structure/unions made entirely of `chars`), and two byte alignment for everything else. Basic data types shorter than a word are promoted to a word when passed as arguments or return values.
Calling conventions for V850
GCC will use up to four registers for passing parameters (`r6` through `r9`). A parameter may be split between registers and memory if it does not fit within the remaining available parameter registers. Alignment of parameters within the parameter list is the same as their basic alignment. This implies that `doubles` and `long long` types need not be 8-byte aligned in parameter lists.
Calling a `varargs` or `stdarg` function does not change how parameters are passed. However, the callee will flush all parameter registers back to a caller allocated parameter flush back area in the stack. This allows the callee to then treat all parameters as if they had been passed in the stack. The caller is responsible for allocating the 16-byte parameter flush back area at the bottom of the current stack. The callee is free to use that 16-byte area for any purpose in a non-`varargs` or a non-`stdarg` function.
Structures greater than 8 bytes in length, passed by value, are automatically converted into pass-by-invisible-reference structures (i.e., the compiler arranges to pass a pointer instead of the entire structure). The callee must make a copy of the structure if the callee modifies the pass-by-invisible reference structure.
Values are returned in the same manner as the GHS compilers, including the use of `r6` as a return-structure-pointer when returning large structures. `r31`, also known as `lp` (link pointer), is used as a return pointer during a call instruction; the callee is responsible for saving `r31` into the stack if the callee performs any additional function calls or uses `r31` as a scratch register.
Stack arguments are located at increasing addresses from `entry_sp`. The `varargs` flush back area uses:

`entry_sp (r6)`
`entry_sp + 4 (r7)`
`entry_sp + 8 (r8)`
`entry_sp + 12 (r9)`

The callee can use the flush back area for any purposes if the callee does not use `varargs` or `stdarg` facilities.
Register allocation for V850
Fixed registers are never available for register allocation in the compiler. By default the following registers are fixed in GCC: `r0` (zero), `r1` and `r3` (sp), `r4` (gp), `r30` (ep). Caller saved registers can be used by the compiler to hold values that do not live across function calls. The caller saved registers are `r2`, `r5` through `r19`, and `r31`. Callee saved registers retain their value across function calls. The callee saved registers are `r20` through `r2` .

Note:
`r6` through `r9` are parameter registers while `r10` and `r11` are function return registers. `r31` is the return pointer.

`r29` is used as the frame pointer in some functions.
GCC will always create a frame pointer when not optimizing. The frame pointer will be eliminated when optimizing, except for functions which allocate dynamic stack space (functions which call `alloca`). Interrupt functions can never have a frame pointer; so, when compiling an interrupt function, you must either specify optimization (using the `-O` option) or by explicitly making the compiler not generate a frame pointer (by using the `-fomit-frame-pointer` option). Interrupt functions can not use `alloca` calls, nor can they have very large stacks (less than 32K, in size).
Stack frame information for V850
The following documentation discusses the stack frame for the V850 processor's usage, especially for the debugging processes. See stack frame and also stack frames for functions taking a variable number of arguments.

- The stack grows downwards from high addresses to low addresses.
- A leaf function need not allocate a stack frame if it doesn't need one.
- A frame pointer need not be allocated.
- The stack pointer shall always be aligned to 4 byte boundaries.
- The register save area shall be aligned to a 4 byte boundary.

Stack frame for V850

`*` FP points to the same location as SP.

Stack frames for functions that take a variable number of arguments have usage as shown by Stack frames for functions taking a variable number of arguments.

Stack frames for functions taking a variable number of arguments

`*` FP points to the same location as SP.

Argument passing for V850
Arguments are passed to a function using (1) registers and (2) memory, if the argument passing registers are depleted. Each register is assigned an argument until all are used. Unused argument registers have undefined values on entry. Use the following rules.

- Quantities of size 8 bytes or less are passed in registers if available, then as memory. Larger quantities are passed by reference. Arguments passed by reference are passed by making a copy of the argument on the stack and passing a pointer to that copy.
- If a data type would overflow the register arguments, then it is passed in registers and memory. A `long long` data type passed in `r9` would be passed in `r9` and in the first 4 bytes of the stack.
- Arguments passed on the stack begin at `sp` with respect to the caller.
- Each argument passed on the stack is aligned on a 4 byte boundary.
- Space for all arguments is rounded up to a multiple of 4 bytes.
- The first argument register is `r6`.
- The last argument register is `r9`.
- A call to a function, procedure, or subroutine uses a `jarl` routine, a `lp` instruction which saves the return address in `r31` (`lp`). The return uses a `jump[r31]` instruction.

Function return values for V850
Scalar or pointer return values are returned in `r10` and sign-extended or zero-extended to 32 bits for types smaller than 32 bits.

- 32-bit floating point values are returned in `r10`.
- 64-bit floating point values are returned in the register pair, `r10` and `r11`.

To call a function which returns a structure or union in C and C++, the address of a temporary of the return type is passed by the caller in `r6`. The function returns the structure value by copying the return value to the address pointed to by `r6`, and copies `r6` into `r10` before returning to the caller.
Compiler issues for V850
The following documentation discusses the ABI for the V850 processor.

- V850-specific command-line options for GCC
- Preprocessor symbols for V850
- Special data areas on the V850
- `depragmaize` for V850
- Structure conversion for V850

V850-specific command-line options for GCC

For a list of available generic compiler options, see GNU CC command options in Using GNU CC in GNUPro Compiler Tools.

The V850-specific command-line options are supported.

`-mep`
`-mno-ep`

Enables (disables) the checking of pointers in the basic blocks and if a pointer is heavily used, it will copy the pointer into the Element Pointer (`r30`) so it can use the shorter SLD and SST instructions for that basic block. The default is `-mep` when optimization is on.

`-mprolog-function`
`-mno-prolog-function`

Enables (disables) the use of external functions to save and restore the registers in the function prologue. The default is `-mprolog-function` when optimization is on.

For more detailed information on the use of the following three compiler options, see Special data areas on the V850.

`-msda=` <`n`>

Enables automatic placement of static / global data in the small data area (`sda`) off of Global Pointer (`r4`). This enables data access with one instead of two 32-bit instructions.

`-mtda=` <`n`>

Enables automatic placement of static/global data in the tiny data area (`tda`) off of Element Pointer (`r30`). This enables data access with one 16-bit instruction instead of two 32-bit instructions.

`-mzda=` <`n`>

Enables automatic placement of static / global data in the zero data area (`zda`) off of Zero Register (`r0`). This enables data access with one instead of two 32-bit instructions.

Preprocessor symbols for V850
By default, the compiler defines the preprocessor symbols as `__v850__`, `__v851__`, and `__v850`.
Special data areas on the V850

There are 3 distinct data areas on the V850: `zda` (zero data area), `sda` (small data area), and `tda` (tiny data area).

- `zda` variables are stored in the `.zdata` and `.zbss` sections, which together must be no more than 64K bytes, unless the bottom area of the address map is reserved for an internal ROM/PROM in which case the limit is 32K. The linker puts them in memory at negative offsets of -1 to -32K from 0, and if no internal ROM/PROM is present, from 0 to +32K as well (so that the zero pointer, `r0`, can be used to point to the variables).

- `sda` variables are stored in the `.sdata` and `.sbss` sections, which together must be no more than 64K bytes. The runtime startup code is responsible for loading up the `gp` global pointer with an address within the region.

- `tda` variables are stored in the `.tdata` section, which must be no more than 256 bytes. The runtime startup code is responsible for loading up the `ep` elemenmt pointer with an address within the region. The `-mep` switch also uses the `ep` element pointer, but restores it after it is done.

It is also possible to use GCC attribute extension to the C language to explicitly specify which data area will contain a given variable. For example, the following declaration's syntax will put the integer variable, `fred`, into the zero data area.

    int __attribute((zda)) fred;

If no special attributes or switches are used, it normally takes two 32-bit instructions to reference any global/static variable (one to get the high bits of the address into a register, and the other to do the memory reference). Both `zda` and `sda` static/global references take one 32-bit instruction, while `tda` references take one 16-bit instruction. Thus, you can put the most frequently used variables in the tiny data area and put most of the remaining variables into either the zero or small data areas to cut down on the size of the code space.
The variable, <`n`> in `-mzda=` <`n`>, `-msda=` <`n`>, and `-mtda=` <`n`> compiler options indicates variable size in bytes. Variables that aren't put into a specific section with an attribute, and whose size is less than or equal to <`n`> bytes, are put into the indicated data section. For `-mtda=` <`n`>, the maximum for <`n`> is 256 bytes. For `-mzda=` <`n`>, the maximum for <`n`> is 32768 bytes. The maximum for `-msda=` <`n`> is 65536 bytes. You can combine these switches, and the compiler first looks at `tda`, then `sda`, and finally, `zda`. The following example's input shows the appropriate declaration to provide.

    -mtda=4 -msda=256

This combination would indicate all static or global variables less than or equal to 4 bytes, which would become `tda` references, while all static or global variables less than 4 and greater than or equal to 256 bytes become `sda` references.
Consider the following code.

    struct fred { int a, int b; };

    int main (void) { return fred.a + fred.b; }

If compiled with no options, the compiler will put the `fred` structure into the normal data section of the program. This means that it will take two 32-bit instructions to fetch the contents of `fred.a`, and another two 32-bit instructions to fetch the contents of `fred.b` for the program. If the program is compiled with a `-msda=8` declaration, then the compiler will put the `fred` structure into the small data area (since `fred` is 8 bytes in length, and the `-msda=8` option tells the compiler to put all variables of size 8 or less into the small data area). Now it will only take one 32-bit instruction to fetch `fred.a`, and one to fetch `fred.b` for compiling. If the program had been compiled with the `-mtda=8` declaration, then `fred` would have been put into the tiny data area, and fetching `fred.a` would have required only one 16-bit instruction.
As an alternative, the following code has been changed.

    struct __attribute__ ((zda)) fred { int a; int b; };

    int main (void) { return fred.a + fred.b; }

When this code is compiled (with or without any special command line options), the `fred` structure is placed into the zero data area and fetching either `fred.a` or `fred.b` requires one 32-bit instruction apiece.
The default behaviour is to place variables into the (ordinary) data section. Adding `_attribute__ ((zda))` forces that particular variable to go into the zero data area, but has no effect on other variables. Specifying `-mzda=` `<n>` on the command line forces all variables whose size is less than or equal to `<n>` bytes into the zero data area. It is up to the programmer to determine what value to use for `<n>`. If the value is too large, then too many variables will be put into the zero data area and error messages will be produced by the linker (after all, the `zda` only has room for 32K bytes of data).
`depragmaize` for V850
`depragmaize` modifies source code and associated header files. `depragmaize` converts uses of certain pragmas in C code to uses of equivalent GCC attributes. Pragmas, often used to implement vendor specific features, are in many circumstances very difficult to maintain both in the compiler and in the source code that maintains them. For those machine-specific features affecting declarations or symbols, attributes are a much better way to implement these features, again both for the compiler maintainer and for the source code maintainer. GCC has a well defined mechanism for adding new attributes to the compiler.
For more information about GCC's attributes, see Using GNU CC or use the `gcc.info` on-line help file.
In order to convert a particular source file, the source file must contain C code compilable by GCC (which, of course, includes ANSI C code as well as any GCC extensions). `depragmaize` only converts a limited set of pragmas; see Conversions for a current list.
`depragmaize` is intended to be simple to use. The following descriptions for suggestions of the conversion process will answer most questions. For instance, see `depragmaize` options for the options that `depragmaize` accepts.

Conversions

`#pragma ghs startXXX` `#pragma ghs endXXX` | `XXX` is `tda`, `sda`, or `zda`. `depragmaize` will add the `__attribute__((section("tda")))` pragma to the appropriate symbols between the start and end pragmas. If the `-R` option is specified, `depragmaize` will also remove these pragmas from the source.
`#pragma ghs interrupt` | To the function containing the pragma, `__attribute__((interrupt))`, `depragmaize` will add `__attribute__((interrupt))`. If the `-R` option is specified, `depragmaize` will also remove this pragma from the source.

To do the conversion, `depragmaize` makes use of GCC to find all the parts of the source that need changing. That's why the source code must be compatible with the GCC compiler source code in order for `depragmaize` to convert it. Unfortunately, most real source code is not just compilable. Usually, some number of compile time options must be passed to the compiler in order for the particular source code to be properly compiled by the compiler. Also, source code is often compiled under a number of different sets of compile time options to produce different executables. See the following documentation for further discussion of such issues. In the simplest case (if your source code is very simple) you would invoke `depragmaize` as the following example declaration suggests (where `<file.c>` is the name of the source code file to be converted).

    depragmaize <file.c>

`depragmaize` and `<file.c>` must be in the current working directory. `depragmaize` will convert `<file.c>` and any header files that the `<file.c>` includes, if those header files reside in the current working directory. The actual conversions done are described in the following discussions. `depragmaize` only converts files that are in the current working directory unless the `-d` option is used. `depragmaize` will save a copy of the unconverted source file in `<file.c>save`, unless the `-N` option is used. Any number of source files can be specified on a single invocation of `depragmaize`.

If a source file, or set of source files, uses header files that are not in the current working directory, and those header files also must be converted, specify with the `-d` option. For instance, the following declaration specifies that `depragmaize` should convert `<file.c>` and any headers used by `<file.c>`, if those headers are in the current working directory or in another directory, `other_directory`.

    depragmaize -d other_directory file.c

Often your source code will require some compile time options to successfully compile.

    -c "-DMACRO1=1 -I../include_files" file.c

The previous declaration will pass `-DMACRO1=1` and `-I../include_files` to GCC. Typically, the kinds of options that will need to be passed to GCC will be `-D` options and `-I` options. Someone familiar with building the source code involved will need to determine the exact list of options required to compile that source.

Note:
Options like `-O` and `-g` are not required for proper conversion, though it will not hurt the process if they are specified.

For some source code, the list of symbols actually seen by the compiler is affected by the options given to the compiler. For instance, use the following example to generate symbol lists.

    #ifdef MACRO1

    int a;

    #else

    int b;

    #endif

If `MACRO1` is defined on the command line, the compiler will see the symbol, `a`, but not `b`; and the opposite if `MACRO1` is not defined. `depragmaize` can only convert code actually seen by the compiler. In a case like this `depragmaize` must be invoked twice, once with `MACRO1` defined, once without such a declaration. Of course, if `MACRO1` does not make code converted, you need not use this definition. For some source code, the actual conversion required will depend on the command line arguments. The most likely example of this would be cases where the tokens of the `#pragmas` changed, depending on the command line arguments. Unfortunately, the complexity of the conversions required by these cases is beyond `depragmaize`'s ability to handle automatically. You will need to make these conversions by hand first, and then let `depragmaize` handle the other more common cases.
Finally, because of the possibility that some source code may need to be run through `depragmaize` more than once to effect complete conversion, and `depragmaize` does not remove the pragma's from the source code until the `-R` option is specified. If your source code does not need to be run through `depragmaize` more than once, you can use `-R` on that invocation, otherwise use `-R` on the last invocation.
`depragmaize` options
The following documentation discusses the `depragmaize` options. The following example shows the standard approach for a `depragmaize` declaration.

    depragmaize [options ...] file ...

Each file and any header files it includes are converted.
Files and headers are only converted if they reside in the current directory or a directory specified by the `-d` option. For each file that is converted, and for which some change is actually made, `depragmaize` will create a copy of the original unconverted file under the name, `XXX.save`, where `XXX` is the name of the converted file (so `file.c` is saved under `file.c.save`). If `XXX.save` already exists, `depragmaize` will not overwrite it, and simply does not do this copy. The `-N` option tells `depragmaize` not to make these copies.

`-V`
`-v`
`--version`

Specifies that `depragmaize` should convert `file.c` and any headers used by `file.c`, if those headers in the current working directory, or in `other_directory`, are being used. This option also causes somewhat more verbose messages to be printed.

`-q`
`--quiet`
`--silent`

Don't print warning and informational messages (only print errors).

`-n`
`--nochange`

Don't actually convert the source files, just print messages about what would be done.

`-c "STRING"`
`--compiler-options "STRING"`

Pass `"STRING"` as options to the compiler during the compilation part of the conversion process.

`STRING` should be a space separated list of options for the compiler used. Use the following example's declaration.

    depragmaize -c "-DMACRO1 -DMACRO2" t1.c

`-R`
`--remove_pragmas`

This option causes `depragmaize` to remove the pragmas from the source in addition to converting them attributes.

`-d <DIRECTORY>`
`--directory <DIRECTORY>`

Add `<DIRECTORY>` to the list of directories containing files which can be converted. The current directory is always on this list. Files are not converted unless they are in a directory on this list.

`-x <FILENAME>`
`--exclude <FILENAME>`

Do not convert `<FILENAME>`.

`-p <COMPILER>`
`--file_name <COMPILER>`

Use `<COMPILER>` as the compiler for the compilation part of the conversion process. By default, `gcc` is used. `<COMPILER>` should be the name of an executable and it must work with a version of GCC which is compatible with `depragmaize`. This is only useful for specifying a a GNU compiler program that is compatible with `depragmaize`, unless that is not on your `PATH`.

`-N`
`--nosave`

Don't keep a copy of the original source.

`-k`
`--keep`

Keep a copy of the intermediate file. Only useful for debugging `depragmaize`.

Structure conversion for V850
Structure conversion is done, using the GCC `offset-info` option.
The `-offset-info output-file` option simplifies access to C struct's from the assembler.
For each member of each structure, the compiler will output a `.equ` directive to associate a symbol with the member's offset in bytes into the structure.
The symbol itself is the concatenation of the structure's tag name and the member's name, separated by an underscore. This option will output to the specified `output-file` an assembler `.equ` directive for each member of each structure found in each compilation. The `.equ` directives for the structures in a single header file can be obtained as follows, where `m.h` is the header containing the structures, and `m.s` is where the directives are output.

    gcc -fsyntax-only -offset-info m.s -x c m.h

The following is a short example of output produced by the `-offset-info` option.

    input file (m.h, for example):

        struct W {

        double d;

        int i;

        };

    struct X {

        int a;

        int b;

    struct Y {

        int a;

        int b;

        };

    struct Y y;

    struct Y yy[10];

    struct Y* p;

    };

    output file (m.s, for example):

        .equ W_d,0

        .equ W_i,8

        .equ Y_a,0

        .equ Y_b,4

        .equ X_a,0

        .equ X_b,4

        .equ X_y,8

        .equ X_yy,16

        .equ X_p,96

The `-offset-info` option has the following caveats.

- No directives are output for bit-field members.
- No directives are output for members who's offsets (as measured in bits) is greater than the word size of the host.
- No directives are output for members who's offsets are not constants. This can happened only in structures which use some gcc specific extensions which allow for variable sized members.

Assembler information for V850
The following documentation discusses the assembler issues for the V850 tools.

- Register names for V850
- Addressing modes for V850
- Floating point values for V850
- Opcodes for V850
- Assembler error messages for V850

For a list of available generic assembler options, see Command-line options in Using `as` in GNUPro Utilities. There are no V850-specific assembler command-line options. The V850 syntax is based on the syntax in NEC's V850 User's Manual.
Register names for V850
You can use the predefined symbols, `r0` through `r31`, to refer to the V850 registers. V850 also has predefined symbols for the following general registers.

`ep` | element ptr, synonym for `r30`
`gp` | global ptr, synonym for ` `r4` '
`hp` | synonym for ` `r2` handler stack ptr, '
`lp` | link ptr, synonym for ` `r31` '
`sp` | stack ptr, synonym for ` `r3` '
`tp` | text ptr, synonym for ` `r5` '
`zero` | zero register, synonym for ` `r0` '

Addressing modes for V850

The assembler understands the following addressing modes for the V850. The symbol, `Rn`, in the following examples refers to any of the specifically numbered registers or register pairs, but not the control registers (where `n` signifies the actual number to specify; see the V850 User's Manual for actual specifications).

`Rn`

Register direct.

`[Rn]`

Register indirect.

`<expr>`

Immediate data (angle brackets are not part of the syntax).

`disp[Rn]`

Register indirect with displacement.

`cccc`

Condition code (`c`, `e`, `ge`, `gt`, `h`, `l`, `le`, `lt`, `n`, `nc`, `ne`, `nh`, `nl`, `ns`, `nv`, `nz`, `p`, `s`, `sa`, `t`, `v`, or `z`).

Floating point values for V850
Although the V850 has no hardware floating point, the assembler supports software floating point. The `.float` and `.double` directives generate IEEE-format floating-point values for compatibility with other development tools.
Opcodes for V850
For detailed information on the V850 machine instruction set, see V850 User's Manual. The assembler implements all the standard V850 opcodes.
Assembler error messages for V850
The following messages output as assembler error messages.

`Error: bad instruction`

The instruction is misspelled or there is a syntax error somewhere.

`Error: expression too complex`
`Error: unresolved expression that must be resolved`

The instruction contains an expression that is too complex; no relocation exists to handle it.

`Error: relocation overflow`

The instruction contains an expression that is too large to fit in the field.

Linker information for V850
For a list of available generic linker options, see Linker scripts in Using `ld` in GNUPro Utilities. In addition, the following V850-specific command-line option is supported:

`--defsym _stack=0xnnnn`

Specify the initial value for the stack pointer. This assumes the application loads the stack pointer with the value of `_stack` in the start up code.

See also linker script for the V850 processor and Producing S-records for V850.

The initial value for the stack pointer is defined in the linker script with the `PROVIDE` linker command. This allows the user to specify a new value on the command line with the standard linker option, `--defsym`.

Linker script for V850

The GNU linker uses a linker script to determine how to process each section in an object file, and how to lay out the executable. The linker script is a declarative program consisting of a number of directives. For instance, the `ENTRY()` directive specifies the symbol in the executable that will be the executable's entry point. Since linker scripts can be complicated to write, the linker includes one built-in script that defines the default linking process.

For the V850 tools, the following example shows the default script for the V850.

Although this script is somewhat lengthy, it is a generic script that will support all ELF situations. In practice, generation of sections like `.rela.dtors` are unlikely when compiling using embedded ELF tools.

    OUTPUT_FORMAT("elf32-v850", "elf32-v850", "elf32-v850")

    OUTPUT_ARCH(v850)

    ENTRY(_start)

    SEARCH_DIR(<installation directory path>);

    SECTIONS

    {

    /* Read-only sections, merged into text segment: */

      . = 0x200000;

      .interp        : { *(.interp)                     }

      .hash          : { *(.hash)                       }

      .dynsym        : { *(.dynsym)                     }

      .dynstr        : { *(.dynstr)                     }

      .rel.text      : { *(.rel.text)                   }

      .rela.text     : { *(.rela.text)                  }

      .rel.data      : { *(.rel.data)                   }

      .rela.data     : { *(.rela.data)                  }

      .rel.rodata    : { *(.rel.rodata)                 }

      .rela.rodata   : { *(.rela.rodata)                }

      .rel.got       : { *(.rel.got)                    }

      .rela.got      : { *(.rela.got)                   }

      .rel.ctors     : { *(.rel.ctors)                  }

      .rela.ctors    : { *(.rela.ctors)                 }

      .rel.dtors     : { *(.rel.dtors)                  }

      .rela.dtors    : { *(.rela.dtors)                 }

      .rel.init      : { *(.rel.init)                   }

      .rela.init     : { *(.rela.init)                  }

      .rel.fini      : { *(.rel.fini)                   }

      .rela.fini     : { *(.rela.fini)                  }

      .rel.bss       : { *(.rel.bss)                    }

      .rela.bss      : { *(.rela.bss)                   }

      .rel.plt       : { *(.rel.plt)                    }

      .rela.plt      : { *(.rela.plt)                   }

      .init          : { *(.init)                       } =0

      .plt           : { *(.plt)                        }

      .text          :

      {

        *(.text)

        /* .gnu.warning sections are handled specially by

            elf32.em.  */

        *(.gnu.warning)

        *(.gnu.linkonce.t*)

      } =0

      _etext = .;

      PROVIDE (etext = .);

      .fini          : { *(.fini)                       } =0

      .rodata        : { *(.rodata) *(.gnu.linkonce.r*) }

      .rodata1       : { *(.rodata1)                    }

      /* Adjust the address for the data segment. We want to

         adjust up to the same address within the page on the

         next page up.  */

      . = ALIGN(32) + (ALIGN(8) & (32 - 1));

      .data          :

      {

        *(.data)

        *(.gnu.linkonce.d*)

        CONSTRUCTORS

      }

      .data1         : { *(.data1)                      }

      .ctors         : { *(.ctors)                      }

      .dtors         : { *(.dtors)                      }

      .got           : { *(.got.plt) *(.got)            }

      .dynamic       : { *(.dynamic)                    }

      /* We want the small data sections together, so

         single-instruction offsets can access them all, and

         initialized data all before uninitialized, so we can

         shorten the on-disk segment size.  */

      .sdata         : { *(.sdata)                      }

      _edata  =  .;

      PROVIDE (edata = .);

      __bss_start = .;

      .sbss          : { *(.sbss) *(.scommon)           }

      .bss           : { *(.dynbss) *(.bss) *(COMMON)   }

      _end = . ;

      PROVIDE (end = .);

      /* Stabs debugging sections.  */

      .stab 0        : { *(.stab)                       }

      .stabstr 0     : { *(.stabstr)                    }

      .stab.excl 0   : { *(.stab.excl)                  }

      .stab.exclstr  0 : { *(.stab.exclstr)             }

      .stab.index    0 : { *(.stab.index)               }

      .stab.indexstr 0 : { *(.stab.indexstr)            }

      .comment       0 : { *(.comment)                        }

    /* DWARF debug sections.

         Symbols in the .debug DWARF section are relative to the

         beginning of the section so we begin .debug at 0. It's

         not clear yet what needs to happen for the others.   */

      .debug          0 : { *(.debug)                   }

      .debug_srcinfo  0 : { *(.debug_srcinfo)           }

      .debug_aranges  0 : { *(.debug_aranges)           }

      .debug_pubnames 0 : { *(.debug_pubnames)          }

      .debug_sfnames  0 : { *(.debug_sfnames)           }

      .line           0 : { *(.line)                    }

    PROVIDE (_stack = 0x3ffffc);

    }

Producing S-records for V850
The following command reads the contents of `hello.x`, converts the code and data into S-records, and puts the result into `hello.srec`.

`v850-elf-objcopy -O srec hello.x hello.srec`

Here are the first few lines of `hello.srec`:

    S00D000068656C6C6F2E7372656303

    S31A00100000000220A6FF0000A880AEFFFF401E2000231E0000403B

    S31A00100015F610003EF6A86E402611002426A8EE40361000263637

    S31A0010002AA86E403E1000273EE06EE7319105460700000636011C

    S31A0010003F00E731B1FD80FFA200031EF4FF0032003A004280FF6E

Debugger issues for V850
There are no V850-specific debugger command-line options.
For all available debugger options, see Debugging with GDB in GNUPro Debugging Tools.
GDB's built-in software simulation of the V850 processor allows the debugging of programs compiled for the V850 without requiring any access to actual hardware. Activate this mode in GDB by the command, `target sim`. Then load code into the simulator by the command, `load`, and debug it in the normal fashion.
The Target Selection window for the GNUPro visual debugger, Cygnus Insight, has additional functionality. Accessible from Insight's Source Window, V850 users developing with ICE select a target by entering the name of the ICE target into the Target Selection window's dialog box.
Stand-alone simulator issues for V850
The simulator supports general registers, `r0` through `r31`, `PC` (program counter, low 24 bits only), and `PSW` (low 5 bits only). It does not support any of the additional system registers or memory mapped registers.
Registers are all uninitialized at startup.
There are no V850-specific stand-alone simulator command-line options.

Top|Contents|Previous|Next